Method for realizing user decision user busy forwarding

ABSTRACT

A method for implementing call forwarding on user-determined user busy, including the following steps of: step 1: after receiving a session request routed by a CSCF from a calling side ( 401, 402 ), an IMS Circuit Switched Control Function (ICCF) on a called side establishing a call with a called terminal having IMS Centralized Service (ICS) capability ( 403 ), and then the called terminal ringing ( 410 ); step 2: sending, by the called terminal, a user-determined user busy message to the ICCF when a called user rejects the call ( 404 ); and step 3: notifying, by the ICCF, a Telecom Application Server (TAS) that the called terminal is in a user-determined user busy state ( 405 ), and the TAS initiating a procedure of call forwarding on user-determined user busy ( 406 ). A method for releasing the established media resources resources and session is also provided.

TECHNICAL FIELD

The present invention relates to IP Multimedia Core Network Subsystem(IMS) centralized services, and more particularly, to a method forimplementing call forwarding on user-determined user busy in IMScentralized services.

BACKGROUND OF THE RELATED ART

An Internet Protocol (IP) Multimedia Core Network Subsystem (IMS), whichis an IP-based network architecture presented by the 3^(rd) GenerationPartnership Project (3GPP), constructs an open and flexible serviceenvironment, supports multimedia applications and provides abundantmultimedia services for users.

The IMS, which is an IP-based telecommunication network architecture andis independent of access technologies, may provide services for a mobilecellular network, such as Global System for Mobile communication (GSM),Universal Mobile Telecommunications System (UMTS), etc., in addition toproviding services for a packet access network, such as General PacketRadio Service (GPRS), Wireless Local Area Network (WLAN), etc.

The mobile cellular network, such as GSM and UMTS, uses a circuitswitching technology, which is called a Circuit Switched (CS) domain andable to provide basic voice services and supplementary services based onvoice services for users. When accessing to the IMS, the CS domainevolves into an access mode, where services are provided entirely by theIMS. Such technology is called IMS Centralized Services (ICS for short).

The IMS centralized services have the following advantages:

(1) the IMS provides uniform services for access modes, such as circuitswitched domain and packet domain, and supports network convergence;

(2) it supports the evolvement of a CS network into an IMS network; and

(3) it supports both a user device with ICS ability and an existing userdevice without ICS ability.

FIG. 1 is a frame diagram of IMS centralized services comprising thefollowing network elements: a User Equipment (UE) 101, a Visited MobileSwitch Center (VMSC) 102, a Home User Server (HSS) 103, a Media GatewayControl Function (MGCF) 104, a Media Gateway (MGW) 105, an IMS CSControl Function (ICCF) 106, a Call Session Control Function (CSCF) 107and a Telecom Application Server (TAS) 108.

Three paths from the UE 101 to the ICCF 106 in an IMS domain through theVMSC 102 are established: a session control path, a bearer control pathand a bearer path, wherein,

The session control path, which passes through the VMSC 102 and the HSS103, is borne on a CS domain and uses unstructured supplementary servicedata (USSD). If there is a PS network in a network where the UE 101 islocated, then session control signaling may be accessed through the PSnetwork.

The UE 101 in the bearer control path accesses to the VMSC 102 usingstandard CS control signaling and accesses to the IMS through the MGCF104 and reaches the ICCF 106 through the CSCF 107.

The UE 101 in the bearer path accesses to the IMS through the VMSC 102and the MGW 105 and establishes a media connection with a remote userdevice of the session.

The IMS centralized services utilize the session control path betweenthe UE 101 and the ICCF 106 to interact with session control informationand establishes and controls media bearer through the bearer controlpath, where the ICCF 106 acts as a user agent of the IMS to access tothe IMS in place of the user equipment.

The TAS 108 may provide various complementary services, such as callholding, call transfer, number display, call forwarding and thus becalled complementary service server.

Call forwarding services are a type of complementary services incommunication systems and comprises call forwarding unconditionally,call forwarding on no answer and call forwarding on busy, wherein,mobile user busy includes network-determined user busy anduser-determined user busy. The network-determined user busy means that auser state recorded by a network is busy, for example, the user is onthe phone; while the user-determined user busy means that a mobile userrefuses to answer a call immediately after receiving a call ringingnotification and his incoming call is transferred to a preset phone orvoice mailbox by a network.

As a telecommunication system, the ICS must support call forwardingservices.

FIG. 2 illustrates a prior art scheme where on a session control path ina CS domain, a user A of an IMS calls a user B with ICS capabilityaccessing from the CS domain, and the user B implements a callforwarding procedure through a user-determined user busy cause valuecontained in a release message. A session between the user B and an ICCFis established using a called process. The procedure shown in FIG. 2will be described below.

201. The CSCF receives a Session Initiation Protocol (SIP) sessionrequest message at a called side initiated from the user A on a callingside to the user B on a called side. The CSCF routes the SIP sessionrequest message to a telecom application server (TAS) in charge of callforwarding services based on initial Filter Criteria (iFC) afterreceiving the SIP session request message.

202. The TAS routes the called SIP session request message to the ICCFthrough the CSCF.

203. After acquiring a roaming number of the user B, the ICCF routes theSIP session request message of the calling user to a MGCF through theCSCF.

204. The MGCF sends an Initial Address Message (IAM) of an ISDN userpart (ISUP) to a VMSC.

205. The VMSC sends a call setup request to the user B, and user Bbegins to ring.

206. The user B rejects the call because of busyness, sends a hang-upmessage to the VMSC, and the hang-up message containing theuser-determined user busy cause value.

207. The VMSC releases resources of this session and sends a releasemessage to the MGCF, the release message containing the user-determineduser busy cause value.

208. The MGCF generates a SIP 486 user busy message based on theuser-determined user busy cause value and sends the SIP 486 user busymessage to the CSCF, which in turn forwards the SIP 486 user busymessage.

209. The ICCF sends back the SIP 486 user busy message to the CSCF,which in turn routes the SIP 486 user busy message to the TAS.

210. The TAS triggers the procedure of call forwarding onuser-determined user busy by a call forwarding logic.

FIG. 3 illustrates a prior art scheme where on a session control path ina CS domain, a user A of an IMS calls a user B with ICS capabilityaccessing from the CS domain, and the user B implements a callforwarding procedure by a TAS. A session between the user B and an ICCFis established using a calling process. The procedure shown in FIG. 3will be described below.

301. The CSCF receives a called SIP session request message initiatedfrom the user A on a calling side to the user B on a called side. TheCSCF routes the SIP session request message to a telecom applicationserver (TAS) in charge of call forwarding services based on initialfilter criteria (iFC) after receiving the SIP session request message.

302. The TAS routes the called SIP session request message to the ICCFthrough the CSCF.

303. The ICCF determines, based on the acquired message at the calledside, that a called terminal is a UE supporting an ICS, and then assignsan ICCF address (which is a dynamically assigned address) to the user Band sends the SIP session request message containing the ICCF address tothe user B using USSD via the session control path in the CS domain.

304. The user B uses the ICCF address as a called number to initiate acall setup request to a VMSC immediately after receiving the SIP sessionrequest message.

305. The VMSC analyzes the ICCF address and sends an Initial AddressMessage (IAM) to a MGCF.

306. The MGCF generates a new SIP session request message and routes itto the CSCF based on the ICCF address, and then the CSCF routes the SIPsession request message to the ICCF based on the ICCF address.

307. After receiving the SIP session request message from the user B,the ICCF sends back a SIP 180 ringing message to the CSCF, which in turnsends back the SIP 180 ringing message to the MGCF.

308. The MGCF sends back an Address Complete Message (ACM) to the VMSCafter receiving the SIP 180 ringing message.

309. The VMSC sends back the SIP 180 ringing message to the user B.

In the step 307-309, the ICCF sends the ringing message to the terminalUE via the bearer control path in the CS domain to notify the UE ofsuccessful setup of the call. The notification of the ICCF is notlimited to the SIP ringing message, and other messages may be used.

310. The user B begins to ring and sends the ringing message to the ICCFusing USSD via the session control path in the CS domain.

The step 310 is a response to the step 303 and may be omitted withoutaffecting the connection of the ICCF.

311. The ICCF sends the SIP 180 ringing message to the CSCF afterreceiving the ringing message (or after receiving the SIP sessionrequest message from the user B in step 307).

312. The CSCF notifies the user B on calling side to ring.

313. The user B is busy now, and cannot answer the session initiated bythe user A on calling side, so the user B rejects the call request andsends a normally disconnecting request to the VMSC, the disconnectingrequest containing a normally releasing message.

314. The VMSC releases resources for this session and sends the releasemessage to the MGCF.

315: The MGCF converts a resources-releasing request into a SIP cancelrequest and sends the SIP cancel request to the CSCF, which in turnroutes the SIP cancel request to the ICCF and releases the sessionbetween the user and the ICCF.

It can be seen from the existing call forwarding procedure that when thecall between the user B and the ICCF is established using the calledprocess, the hang-up request sent to the VMSC by the user B may containa user-determined user busy cause value when the user B refuse to answerthe call because of busyness, thereby implementing a call forwardingservice user-determined user busy. However, when the call between theuser B and the ICCF is established using the calling process, the callforwarding service on user-determined user busy cannot be implemented.This is because, when the user B refuse to answer the call due tobusyness, the user B is a calling party, the disconnecting request thathe sent to the VMSC is incapable of carry the user-determined user busycause value but only a normally disconnecting cause value. Thus, whenthe call between the user B and the ICCF is established using thecalling process, the call forwarding service on user-determined userbusy cannot be implemented using the existing technology.

SUMMARY OF THE INVENTION

A technical problem to be solved by the present invention is to providea method for implementing call forwarding on user-determined user busyin IMS centralized services such that a call forwarding service onuser-determined user busy can be implemented when a call between an IMSCircuit Switched Control Function (ICCF) and a called user isestablished, whether using a calling process or a called process.

In order to solve the technical problems described above, the presentinvention provides a method for implementing calling forwarding onuser-determined user busy, the method applies to a call process of an IPMultimedia Core Network Subsystem (IMS) centralized services andcomprises the following steps of:

step 1: establishing a call, by an ICCF on a called side, with a calledterminal having IMS Centralized Service (ICS) capability after the ICCFreceives a session request routed by a Call Session Control Function(CSCF) from a calling side, and then the called terminal ringing;

step 2: sending, by the called terminal, a user-determined user busymessage to the IMS CS control function when a user of the calledterminal rejects the call; and

step 3: notifying, by the ICCF, a Telecom Application Server (TAS) thatthe called terminal is in a user-determined user busy state through theCSCF, and the TAS initiating a procedure of call forwarding onuser-determined user busy.

Further, the method comprises step 4 subsequent to the step 3: releasingmedia resources and a session established between the called terminaland the ICCF.

Further, in the step 1, the call between the called terminal and theICCF is established using a calling process or a called process.

Further, in the step 2, the called terminal uses UnstructuredSupplementary Service Data (USSD) on a session control path in a circuitswitched domain to send the user-determined user busy message to theICCF.

Further, in the step 2, after receiving the user-determined user busymessage from the called terminal, the ICCF converts the user-determineduser busy message into a Session Initiation Protocol (SIP) 486 user busymessage, and notifies the TAS of the SIP 486 user busy message.

Further, a first way of releasing the media resources is: the calledterminal using the Unstructured Supplementary Service Data (USSD) tosend the user-determined user busy message to the ICCF and initiatingactively a media resource release procedure after the ICCF receives theuser-determined user busy message.

Further, after using the USSD to send the user-determined user busymessage to the ICCF, the called terminal initiates actively the mediaresource release procedure after a delay until the ICCF receives theuser-determined user busy message.

Further, a second way of releasing the media resources is: after thecalled terminal uses Unstructured Supplementary Service Data (USSD) tosend the user-determined user busy message to the ICCF, the IMS CScontrol function uses the USSD to return an acknowledgement message tonotify the called terminal that the resources can be released, and thenthe called terminal initiating actively a media resource releaseprocedure.

Further, a third way of releasing the media resources is: after thecalled terminal uses Unstructured Supplementary Service Data (USSD) tosend the user-determined user busy message to the ICCF, the ICCFinitiating actively a media resource release procedure.

In the present invention, the ICCF is notified of the user-determineduser busy state of the called user using the USSD and then the ICCFnotifies the TAS to activate the procedure of call forwarding onuser-determined user busy. Thus the procedure of call forwarding onuser-determined user busy can be implemented reliably, whether the callbetween the called user and the ICCF is established using a callingprocess or a called process. In addition, the present invention alsoprovides a method for releasing the established media resources andsession.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a networking frame diagram of IP Multimedia Subsystem (IMS)centralized services.

FIG. 2 is a flow chart of a procedure of call forwarding onuser-determined user busy in which a session between an ICCF and acalled user is established using in a called process in existing IMScentralized services.

FIG. 3 is a flow chart of a procedure of call forwarding onuser-determined user busy in which a session between an ICCF and acalled user is established using in a calling process in existing IMScentralized services.

FIG. 4 is a flow chart of the first embodiment of implementing callforwarding on user-determined user busy in IMS centralized services inaccordance with the present invention.

FIG. 5 is a flow chart of the second embodiment of implementing callforwarding on user-determined user busy in IMS centralized services inaccordance with the present invention.

FIG. 6 is a flow chart of the third embodiment of implementing callforwarding on user-determined user busy in IMS centralized services inaccordance with the present invention.

PREFERRED EMBODIMENTS OF THE INVENTION

The main innovative points of the present invention are as follows: inIMS centralized services, when a calling user calls a called user, auser-determined user busy cause value contained in USSD may be sent toan ICCF on a session control path in a CS domain such that the ICCFnotifies a TAS to initiate a procedure of call forwarding onuser-determined user busy, whether a session between the called user andthe ICCF is established using a calling process or a called process.

The technical scheme of the present invention will be described indetail below in conjunction with the accompanying drawings and specificembodiments.

In all of the following embodiments, a called user is a user of ICS,i.e., a user with IMS centralized control service capability accessingfrom a CS domain; application scenario is that access is from a CSnetwork without PS network coverage, and the USSD technology and ICCPprotocol are used.

Embodiment 1

FIG. 4 illustrates an implementation flow of embodiment 1 in accordancewith the present invention. Its specific steps will be described indetail below.

401. After receiving a called SIP session request message initiated byuser A on calling side to user B on called side, a CSCF routes thesession request message to a Telecom Application Server (TAS) in chargeof call forwarding services according to initial Filter Criteria (iFC).

402. The TAS routes the called session request message to an ICCFthrough the CSCF.

403. A call setup request is initiated between the ICCF and the UserEquipment B (UE-B) through a called process or a calling process and theUE-B rings.

If the called process is used, the ICCF establishes a session with thecalled UE-B through the CSCF based on a number of the UE-B and the UE-Brings, which is described in detail in the steps 203-206.

If the calling process is used, the ICCF assigns an ICCF address to theUE-B and sends the session request message containing the ICCF addressto the UE-B via a session control path on a CS domain, the UE-B uses theICCF address as a called number to send the call setup request andestablishes a session with the ICCF via a bearer control path, and theICCF responds to the UE-B with a ringing message such that the UE-Brings, which is described in detail in the steps 303-312.

404. The user B is unable to answer the session initiated from the userA on calling side because of busyness and then rejects the call request,and the UE-B sends a user-determined user busy message contained in USSDto the ICCF on the session control path in the CS domain.

405. The ICCF generates a SIP 486 user busy message (SIP 486 means thatthe terminal user is busy) and sends it to the CSCF, and then CSCFroutes the SIP 486 user busy message to the TAS after receiving it.

406. The TAS triggers a procedure of call forwarding on user-determineduser busy according to a call forwarding logic after receiving the SIP486 user busy message.

407. After sending the user-determined user busy message to the ICCFusing the USSD in the step 404, the user B sends a release message to aVMSC to release media resources from the user B to the VMSC afterdelayed until the ICCF receives the user-determined user busy message inthe USSD.

That the user B takes the delay mainly intends to allow the ICCF receivethe user-determined user busy message in the USSD first and be notifiedto start the procedure of call forwarding on user-determined user busyprocedure. If the user B does not take the delay, it is possible that aresource release message of the user B arrives at the ICCF first, thusresulting in the releasing of the session between the calling user andthe called user.

If that the user B sends the release message to the VMSC while sendingthe user-determined user busy message using the USSD to the ICCF doesnot cause the resource release message of the user B to arrive at theICCF first but cause the session between the called user and the callinguser to be released, then the user B may send the release message to theVMSC while sending the user-determined user busy message using the USSDto the ICCF.

408. The VMSC sends the release message of ISUP to a MGCF to releasemedia resources from the VMSC to the MGCF.

409. The MGCF generates a SIP cancel message and sends it to the ICCFthrough the CSCF to release the session between the user B and the ICCF.

Embodiment 2

FIG. 5 illustrates a flow of implementing embodiment 2 in accordancewith the present invention. The difference between embodiment 1 shown inFIG. 4 and embodiment 2 consists in an implementation method of a mediaresource release procedure. FIG. 4 illustrates a media resourcereleasing procedure initiated actively by the user B, while FIG. 5illustrates a media resource releasing procedure initiated by the ICCF.Steps 501-506 correspond to steps 401-406 respectively and will not berepeated herein. The different steps will be described in detail below.

507. In addition to sending the SIP 486 user busy message to the TAS instep 505, the ICCF sends a SIP cancel message to a MGCF and release thesession between the ICCF and the user B.

508. The MGCF converts the SIP cancel message into a release message ofISUP to send it to the VMSC to release media resources from the MGCF tothe VMSC.

509. The VMSC sends the release message to the UE-B to release mediaresources from the VMSC to the user B.

In this case the UE-B no longer sends the release message to the VMSC.

Embodiment 3

FIG. 6 illustrates a flow of implementing embodiment 3 in accordancewith the present invention. The difference between embodiment 1 shown inFIG. 4 and embodiment 3 also consists in an implementation means of amedia resource releasing procedure. In FIG. 4, after sending auser-determined user busy message to the ICCF using the USSD, the user Binitiates actively the media resource release procedure after delayedfor a period of time, while in FIG. 6, after the user B sends auser-determined user busy message to the ICCF using the USSD, the ICCFin turn sends a confirmation message to the user B using the USSD, andthen the user B initiates the media resource release procedureimmediately after receiving the confirmation message. So, steps 601-606correspond to step 401-406 respectively. The steps subsequent to step606 will be described in detail below.

607. After receiving the SIP 486 user busy message sent by the UE-B instep 605, the ICCF sends a confirmation message to the UE-B using theUSSD via the session control path in the CS domain to notify the UE-Bthat media resources from the ICCF to the UE-B may be released.

608. The user B sends a release message to the VMSC to release mediaresources from the user B to the VMSC.

The subsequent steps 609-610 correspond to steps 408-409 respectivelyand will not be repeated herein.

Of course, there may be a variety of other embodiments in accordancewith the invention. Various corresponding modifications and variations,which are within the protection scope of the invention as defined by theappended claims, may be made by those skilled in the art in light of theinvention without departing from the spirit and scope the invention.

Industrial Applicability

In the present invention, an ICCF is notified of a user-determined userbusy state of a called user using USSD and then the ICCF notifies a TASto activate a procedure of call forwarding on user-determined user busy.Thus the procedure of call forwarding on user-determined user busyprocedure can be implemented reliably, whether the call between thecalled user and the ICCF is established using a calling process or acalled process.

1. A method for implementing call forwarding on user-determined userbusy, applied in a call process of an Internet Protocol Multimedia CoreNetwork Subsystem (IMS) centralized service, the method comprising thefollowing steps of: step 1: establishing a call, by an IMS CircuitSwitched Control Function (ICCF) on a called side, with a calledterminal having IMS Centralized Service (ICS) capability after the ICCFreceives a session request routed by a Call Session Control Function(CSCF) from a calling side, and then the called terminal ringing; step2: sending, by the called terminal, a user-determined user busy messageto the ICCF when a user of the called terminal rejects the call, whereinthe called terminal uses Unstructured Supplementary Service Data (USSD)on a session control path in a circuit switched domain to send theuser-determined user busy message to the ICCF; and step 3: notifying, bythe ICCF, a Telecom Application Server (TAS) that the called terminal isin a user-determined user busy state through the CSCF, and the TASinitiating a procedure of call forwarding on user-determined user busy.2. The method according to claim 1, further comprising step 4 subsequentto the step 3: releasing media resources and a session establishedbetween the called terminal and the ICCF.
 3. The method according toclaim 2, wherein releasing the media resources includes: the calledterminal using Unstructured Supplementary Service Data (USSD) to sendthe user-determined user busy message to the ICCF and initiatingactively a media resource release procedure after the ICCF receives theuser-determined user busy message.
 4. The method according to claim 3,wherein after using the USSD to send the user-determined user busymessage to the ICCF, the called terminal initiates actively the mediaresource release procedure after a delay until the ICCF receives theuser-determined user busy message.
 5. The method according to claim 2,wherein releasing the media resources includes: after the calledterminal uses Unstructured Supplementary Service Data (USSD) to send theuser-determined user busy message to the ICCF, the ICCF using the USSDto return an acknowledgement message to notify the called terminal thatthe resources can be released, and then the called terminal initiatingactively a media resources release procedure.
 6. The method according toclaim 2, wherein releasing the media resources includes: after thecalled terminal uses Unstructured Supplementary Service Data (USSD) tosend the user-determined user busy message to the ICCF, the ICCFinitiating actively a media resources release procedure.
 7. The methodaccording to claim 1, wherein in the step 1, the call between the calledterminal and the ICCF is established using a calling process or a calledprocess.
 8. The method according to claim 1, wherein in the step 2,after receiving the user-determined user busy message from the calledterminal, the ICCF converts the user-determined user busy message into aSession Initiation Protocol (SIP) 486 user busy message, and notifiesthe TAS of the SIP 486 user busy message.